-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Implement deprecation infrastructure #9857
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is pretty sweet, thanks for putting this together. I have some high-level comments about what this looks like below. Thanks again!
Looks like new artifacts were built from this PR. Get them here!Artifact URLs |
Adding an information message here if user uses deprecated options/plugins would be nice: telegraf/cmd/telegraf/telegraf.go Lines 267 to 271 in 06edde6
(This will go into any configured logfile, instead of the pre-config-completely-loaded stdout/stderr messages) |
You might also update docs/COMMANDS_AND_FLAGS.md |
@Hipska good catch. Done. |
📦 Looks like new artifacts were built from this PR. Expand this list to get them here! 🐯Artifact URLs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@reimda and I were talking through this during pairs. One of the scenarios we ran across is what happens when a plugin is removed. When we remove a plugin it would be nice to be able to remove the source code and delete it from the all.go file and be done with it. As this is currently written, we would need to keep the plugin around for the deprecation code to get called.
Also, a similar question for the removal of fields. In order to finally remove the field but also notify the user, how will this work without leaving the field in?
Dave and I tried to fake this with a _
or a _foobar
and neither worked as we expected. Have you tried this out?
Thanks!
@powersj, @reimda I'm not sure I do understand your examples. IMO a plugin/plugin option is deprecated in a certain version (e.g. 1.20). In this example I do expect the user to receive a warning starting from version 1.20 on. The next step is, after a grace time of e.g. 4 minor updates (>=1.24) or one major + 4 minor (>= 2.4), the warning turns into an error (we might want to allow starting nonetheless with a cmdline switch or similar). Now, maybe after another gracetime (e.g. >= 1.28 or 2.8) the plugin or option can be removed at any time without further notice. Of course the deprecation warning is then gone when the plugin or plugin option is removed, but that's correct as there is no deprecated plugin/option any longer. What am I missing here? Is your intention to remove the plugin/plugin option and still get a warning? If so why? A plugin removed will trigger config errors, so there is no silent fail anyway... |
📦 Looks like new artifacts were built from this PR. Expand this list to get them **here**! 🐯Artifact URLs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking awesome! I have some questions and one issue when trying this out setting the build_version to 2.0.0
.
This reverts commit 3b95f31.
…irect) dependency.
…s a (indirect) dependency." This reverts commit 184d745.
📦 Looks like new artifacts were built from this PR. Expand this list to get them here ! 🐯Artifact URLs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 - need Dave to sign off, so that will happen early next week. I do know that he will probably comment on the behavior of when RemovalIn
is not set. I think his desire, and I agree with it, is that we are explicit anytime we deprecate a plugin and that means setting the RemovalIn
value.
Just stumbled on this; What about deprecation of agent/global config options? |
@Hipska this is out of scope for this PR. Getting this to the current state was already a lot of (non-technical) discussions and decision-making, so I suggest to postpone more features to future PRs. |
@powersj if requiring a However, I also want you to consider developers trying to deprecate things. Currently, it is possible but not mandatory to set the |
@srebhan Could you resolve the conflict? Otherwise it's ready to merge. |
Required for all PRs:
relates to #9478
This PR adds the possibility to deprecate plugins in a machine-readable form by adding an entry to the
deprecations.go
file in the plugin category (e.g.inputs
). This entry needs to at least contain the version since when the plugin was deprecated and a notice for the user e.g. suggesting replacements. Furthermore, you can also deprecate plugin config-options by adding adeprecated
tag likealso providing a "since" version and a hint separated by a colon.
Both, plugin and option deprecation, can also specify a 'removal in' version, specifying the version when removal of the plugin or option is planned. For the
deprecated
tag you simply add it as a second version after since, e.g.The new framework is then used to print deprecation warnings (or errors) during startup of telegraf or to print a list of deprecated options or plugins via
telegraf --deprecation-list
.